👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can either: Add ready label to the PR or enable auto-merge.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

@allenh1 Merged — thank you, and apologies: this was a regression I introduced in 70a33886bd, the very commit you were building on. Not a pre-existing gap you happened to hit.

What I broke. While resolving a dspark.py conflict during the 209-commit upstream merge, I took "ours" for the load_weights hunk and dropped upstream vllm-project#49415's shared-expert handling. I scoped that decision off the upstream PR's title — "Fix DeepSeek-V4 DSpark draft shared-expert padding for TP > 8" — and reasoned it didn't apply to us at TP=2. I never read that the diff contains two changes, and the title only describes one of them:

• the padding (TP-conditional) — for this geometry it is a genuine no-op: moe_intermediate_size=2048 with weight_block_size=128 divides evenly at every TP, so pad == 0 at TP=1/2/4/8/16;
• the .w2 → .down_proj rename (unconditional) — and this is the load-bearing half. The checkpoint ships shared_experts.w2.* while the module exposes shared_experts.down_proj, so params_dict[name] raises KeyError and EngineCore aborts. It happens before any TP sharding, so it breaks at every TP size, not just > 8.

Reproduced and verified on our 2-node GB10 (TP=2) with DeepSeek-V4-Flash-DSpark, method=dspark, num_speculative_tokens=5:

Note it fires on layers.0, i.e. the DSpark model's own decoder layers — slightly broader than the draft-only scope I'd assumed.

Landed on codex/ds4-sm120-min-enable + ds4-sm120-preview-dev, tag sm120-pr-41834-stable-preview-20260727b. No impact on the default MTP path, as expected — DSpark is unreachable under method="mtp" (it's a single-valued enum), and GSM8K came back byte-identical (0.9567854435178166) with coherence c=12 24/24.

The thing I'll take away: our entire gate battery is structurally blind to this class of regression, because DSpark is dead code on the config we run — every gate stayed green while the DSpark path was broken. "Does this affect our setup?" was the wrong question for a shared branch. When I can't exercise a code path, deleting it is the risky option, not the safe one.

Thanks for debugging it and shipping the fix on a commit that was only hours old — that turnaround is genuinely appreciated.

Closing as landed — the change is on codex/ds4-sm120-min-enable and ds4-sm120-preview-dev as commit 520c25949c, tag sm120-pr-41834-stable-preview-20260727b.

To be precise about why this shows as closed rather than merged: I cherry-picked your commit onto the branch head (which had already moved past your base 70a33886bd), so the SHA differs and GitHub could not auto-detect it. The content is byte-for-byte identical — git patch-id matches at 6930872632ffed4f — and your authorship is preserved: git log shows Author: Hunter L. Allen <hunter@allen-software.com>.

Merging the PR button-side would only add an empty merge commit and move a branch head I've already validated end-to-end against this exact SHA, so I'd rather keep the history pointing at the tested commit.

Thanks again — and to repeat the important part from above: this was a regression I introduced in 70a33886bd by dropping upstream vllm-project#49415's .w2 → .down_proj rename during a merge conflict, having scoped that call off the upstream PR's title instead of reading its diff. You found and fixed it on a commit that was hours old. Much appreciated.